Programming languages and their development environments (compilers, linkers, debuggers, etc.) provide arrangements for code reuse, in particular code from ISVs or 3rd party vendors. Typically, vendors provide source code header files, allowing the user to write programs to invoke the vendor's code and then to compile the code, and libraries used during linking, allowing execution access to the vendor's code. In many ways, this summary of exposed vendor materials is limited to the minimal amount of actual code exposure the consumer needs to use the vendor product, i.e. the full source code is not required. (Herein the term “package” is used in the sense described, yet is not limited to ISV or 3rd party vendor code, but more generally to any well defined body of code used by a program in development or at runtime. There is also designated herein by the terms “package identity” or “package descriptor”, any information about the package, above and beyond its installation, including, e.g., its name, version, product description, web link references, etc.) It turns that once these directories are specified through various access file paths, and even when the directory name is indicative of the 3rd party's package by name, it is still unclear to the user, if an application actually uses a particular package from a given vendor. This may be due to duplicate file names in other directories picked up through higher precedence of paths (applying to both the compiler and linker). For example, there are several popular implementations of the C++ Standard Template Library (STL). However, it is a tedious manual analysis of different paths to figure out which STL was used on a file compilation or build.
Having clear identity of a utilized software package is important for a variety of reasons, among which are the following:                (1) Some implementations are more efficient than others & identifying the implementation actually used is critical to program performance.        (2) It is important to be consistent on packages used by the compiler and those by the linker.        (3) On package upgrading, the user application may need to be modified.        Knowing the locations in user application code where package APIs are used, will assist user to upgrade the application accordingly.        
While in many cases naming conventions may out sort much of this, especially between different vendor packages, there are no guarantees. Also, naming conventions are likely to be similar when one upgrades a given vendor's package—so in this case, confusion regarding the package used by compiler and linker could easily occur.
Problematic here is not simply a case of the tools providing path information of the sets of paths they used. As mentioned, path names need not indicate the package's identity. Particularly, a need has been recognized in connection with providing a stronger identity of package than simply the sets of paths to access.